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Abstract — D-STAR was the first digital voice system designed by radio amateurs specifically for ama- 
teur radio use. However, it relies on a proprietary, patented codec, which has been the subject of con- 
troversy among amateur radio operators and regulatory authorities. In this paper, we present a proto- 
col extension, that enables the optional use of Codec 2 in voice streams — an open-source and patent- 
free alternative to the default codec. The "D-STAR vocoder extension" has been implemented in a 
series of accompanying, open-source software projects, which focus on seamless interoperability with 
current D-STAR deployments. Transcoding voice streams between codec variants is possible with a 
custom version of the popular xlxd reflector. In addition, we introduce Estrella, a software-only, ra- 


dio-like desktop and mobile application, for over-the-network communications. 


1. Introduction 


Digital Smart Technologies for Amateur Radio (D-STAR) is a digital voice and data standard designed 
for amateur radio use [1, 2, 3]. The research leading to the original specification [4], published in 2001, 
was funded by the Japanese government and led by JARL, in a joint effort with Japanese radio equip- 
ment manufacturers. D-STAR digital voice transmissions require less bandwidth than analog FM and 
provision a small percentage of the stream to be used for arbitrary data, like text messages or GPS in- 
formation. D-STAR repeaters may have modules in several bands (most commonly VHF and UHF) and 
are capable of forwarding streams from one band to another, or through a special "gateway" module 
which "links" the repeater to some other Internet-based endpoint. Digital voice, once picked up by a re- 
peater or a "hotspot" (a local, low-power, radio-to-Internet gateway), can be easily relayed over the net- 
work to other physical or virtual repeaters (called "reflectors"), allowing users to participate in pre-estab- 
lished or ad hoc worldwide talk groups [5, 6]. 


However exciting new technologies may be — especially to amateur radio operators, D-STAR was re- 
ceived early on with mixed reviews. Two were the most prominent causes of criticism: the availability of 
products from a limited set of manufacturers at a relatively high price point, and the use of a closed- 
source, proprietary codec for compressing raw, digitized voice into a low-bitrate stream and vice versa. 


Both points are still valid — almost 20 years after the introduction of the standard. 


Most of the D-STAR equipment available is manufactured by ICOM, Inc., which almost solely supports 
and promotes D-STAR technology [7, 8] (actually, "D-STAR" is an ICOM registered trademark). And 
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while the protocol defines the packaging and modulation details, it does not define the format of addi- 
tional data inside voice streams, routing protocols, and other relevant extensions that are necessary to 
support end-to-end D-STAR network deployments and associated applications. ICOM uses proprietary 
implementations of several D-STAR functions [9, 10], which throughout the years have been reverse- 
engineered, in order to enable building custom D-STAR radios, repeaters [11], and even faster and more 
efficient routing mechanisms [12, 13]. The current ability of D-STAR to support such a variety of con- 
figurations and transparently bridge to other digital voice systems (like DMR and System Fusion), has 
been largely driven by a large collection of open-source software and hardware, supported by a vibrant 
community of amateur radio operators, repeater builders/maintainers, and hardware homebrewers, that 
continuously devise and implement innovative solutions (a wealth of historical information is included 
in [14], while early practical examples are shown in [15, 16]) 


The result of this effort is that a fully operational D-STAR network backbone (repeaters, reflectors, as 
well as routing and bridging functions) can now be completely implemented using open software, run- 
ning on low-cost, commodity devices. However, this is not the case with end-user radios. The propri- 
etary codec used by D-STAR, which is available in the form of a hardware chip, renders do-it-yourself 
radios very difficult to construct. While there have been some software implementations that interface 
with a chip attached via USB on a remote machine over the network (like DVTool [17] or BlueDV [18]), 
users mostly prefer the convenience of a self-contained hardware radio — still with a limited choice of 


options at relatively high price points. 


Advanced Multi-Band Excitation (AMBE), the codec used by D-STAR, was initially selected by the de- 
signers as the only practical option available at the time. There has been some discussion on what will 
happen when the respective patent held by Digital Voice Systems, Inc. will expire (if it is actually valid 
and has not already [19]), however an open implementation would also require a significant amount of 
information made publicly available by the company, which is most probably unexpected. In practice, 
variations of the AMBE codec are used in most well-known contemporary digital voice modes, so the 
codec selection is no longer a source of strong dispute; the proprietary codec issue has even resulted in a 
government ban of the mode all together in France. An alternative to AMBE, Codec 2, has been avail- 
able for some time now. Codec 2 is open-source and patent-free, capable of compressing speech to very 
low bit-rates [20]. Moreover, it has already been used in amateur radio applications, most notably as an 


integral part of FreeDV, a digital voice mode for HF [21]. 


In this paper, we present a protocol extension to enable the optional use of Codec 2 instead of AMBE in 
D-STAR communications. The possibility of such an implementation had been discussed in the past 
[22], but — to our knowledge — had never been realized. The open source codec, will hopefully address 
both aforementioned issues, enabling the emergence of affordable, easy-to-build D-STAR radios, cover- 
ing a wide spectrum ranging from software-only solutions connecting directly to reflectors, to complete- 


ly independent hardware devices. Having D-STAR endpoints with no hardware requirements may also 
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allow an entirely new range of network-based applications, either stand-alone, or as interfaces to exist- 


ing, external systems. 


The changes to the protocol, along with their implications, are discussed in detail in the following chap- 
ter. In summary, a currently unused header flag is employed to mark the codec type in voice frames. This 
work is not meant to replace current D-STAR deployments, but augment them in a fully compatible way. 
To this end, we have implemented a reflector (based on xlxd [23]) that is capable of transcoding between 
AMBE and Codec 2 streams. The reflector is part of a series of extension-compatible, open-source soft- 
ware solutions, which also includes a set of command line utilities to experiment with the extension and 


a software-only client, called "Estrella", available in desktop and mobile versions. 
2. Design 


The D-STAR protocol specification defines the bit framing used to transmit either data or voice streams. 
Each stream begins with a synchronization pattern, followed by a header, and — in the case of voice 


communications — a variable number of alternating voice and data frames (Fig. 1) [24]. 


8 8 8 64 64 64 64 32 16 
Flag 1 | Flag2 | Flag3 | Dst. Rpt. Call. | Dpt. Rpt. Call. | Comp. Call. Own Call. 1 | Own Call. 2 


- 


72 24 bits 


328 72 24 72 24 
Figure 1: Overview of a D-STAR voice stream 


The header, which is 328-bits long carries primarily addressing and routing information: who is sending 
the stream, where it is headed, through which repeater or gateway, etc. (It is actually coded into 660 bits 
when transmitted, after bit interleaving and scrambling.) Except callsigns and 2 trailing bytes for the 
checksum, the header also includes 3 distinct 1-byte long "flags" for identifying the type of communica- 
tion, triggering control functions, and — what is of particular interest here — protocol expansion. Specifi- 


cally, "Flag 3" has by default all 8 bits set to zero; any other value is undefined and left for future use. 


The 72-bit long voice frames carry the data from the AMBE codec, while the 24-bit long data frames 
which are interleaved between them, help in synchronization and are commonly used to provide redun- 
dant copies of the header, text messages, and other information, like sender location. The AMBE codec 
encodes speech at 3600 bps, including error-correction information. Thus, each 72-bit voice frame (9 
octets) corresponds to exactly 20 ms of voice. No other bits in the D-STAR stream are relevant to voice 


information. 
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In the following paragraphs, we will present in detail how the unused bits of Flag 3 can be exploited in 
order to extend the D-STAR protocol with Codec 2 support. We propose setting specific bits in Flag 3 to 
signify different content types of the voice frame. Two variants are supported: one with higher voice 
quality but no forward error correction (FEC), and another one with slightly higher voice compression, 


but with additional error-correction data piggybacked at the end of each encoded voice chunk. 
2.1. D-STAR vocoder extension 


The "D-STAR vocoder extension" uses the Flag 3 byte of the header, to mark the vocoder type in the 


voice frames as follows (in accordance to section 2.1.1, page 4, of the D-STAR specification): 


Bit Meaning ‘Function 
0000000x Vocoder 0: AMBE (backwards compatible) 
1: Codec 2 
000000x1 Mode 0: Codec 2 3200 (160 samples/20 ms into 64 bits) 


1: Codec 2 2400 (160 samples/20 ms into 48 bits) plus FEC (22 bits) 
00000100 to11111111 Undefined Use for future expansion 


Table 1: Possible values of Flag 3 with the D-STAR vocoder extension 


Toggling the least-significant bit of Flag 3 switches between backwards-compatible AMBE mode and 
the new Codec 2-based voice frames. A second bit controls the bitrate of the codec and the presence of 
FEC. 


Codec 2 has several modes, the highest bitrate one working at 3200 bps — a close match to 3600 bps. 
Note, however, that the Codec 2 algorithm only provides speech processing and the resulting stream 
does not include any error-correction. 20 ms of voice in Codec 2 3200 mode require 64 bits (8 octets), 
which fit in the 72-bit space available, but do not leave much space for implementing FEC. The next 
available Codec 2 mode, which operates at 2400 bps, requires just 48 bits (6 octets) to encode a speech 
waveform of equal duration, which leaves an adequate amount of bits free, to protect the first 24 bits of 
the voice data with two applications of the (23, 12) Golay code. Each application produces an additional 
11 bits that are used for error correction at the receiving side, raising the grand total of voice-related bits 
to 70; 2 short of the space available. (In practice, Codec 2 2400 mode also has 2 spare bits, so the trans- 
mission really requires 68 bits.) 


This technique of employing FEC, is similar to what is implemented by FreeDV, a digital voice mode 
built upon Codec 2: FreeDV 1600 mode uses Codec 2 1300 mode to encode 40 ms of speech to 52 bits 
of voice data and then applies a (23, 12) Golay code to protect a 12-bit selection of those 52 bits. In 
Codec 2-encoded voice samples, some bits are more "important" than others. In the context of the im- 
plementation discussed here, it has been decided to apply the Golay code to the the first 24 bits of the 
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resulting data chunk encoded with Codec 2 2400 mode, which contains all the voicing and pitch/energy 
bits, plus the first 14 bits of harmonic magnitudes (Line Spectrum Pairs — LSPs). 


2.2. Discussion 


The proposed protocol extension is backwards compatible, so traffic using Codec 2 will pass through 
current D-STAR hardware (repeaters, hotspots, etc.) and software (repeater controllers, reflectors, etc.). 
Of course, hardware transceivers with AMBE chips are incompatible and cannot be used to directly 


communicate with Codec 2 extension implementations. 


Interoperability between vocoder modes can be established using Internet-based D-STAR reflectors, in a 
similar fashion that they are currently being widely used to transcode and bridge between D-STAR, 
DMR, and System Fusion. In particular, in the next chapter we will discuss how xlxd, which is the most 
widespread software used in this setup, has been extended to allow transparent communications between 
AMBE-based devices and Codec 2-based, software-only clients. Note that although early tests have con- 
firmed that xlxd is indeed compatible to pass through Codec 2-based transmissions without any changes, 
we have selected to apply a different connectivity setup for clients that support the extension (on a dif- 
ferent UDP port using the familiar DExtra protocol [25], which has been named "DExtra Open"), in or- 
der to avoid user confusion and establish a fully compatible path for trouble-free adaptation of the new 
mode. Codec 2-based clients are thus "isolated" from their AMBE-only counterparts and respective 


streams are properly transcoded in order to allow cross-codec interaction. 


The wide-spread use of Internet-based digital voice, primarily in the form of talking through hotspots, 
but also via desktop/mobile applications — like DVTool/BlueDV, is the main reason it has been decided 
to allow selecting between the 2 variants of Codec 2. For over-the-Internet communications, FEC is not 
really necessary, as malformed UDP packets — however rare — are dropped by the networking layer and 
never reach the application. It is therefore advised to always use Codec 2 3200 mode in such setups and 


enjoy the slight increase in voice quality. 


In fact, we expect that dropping the AMBE codec from the protocol, hence the requirement of interfac- 
ing with a hardware chip, will allow a new generation of software-only clients to be implemented. Such 
desktop or mobile clients could directly communicate with each other, but to keep up with the usage 
paradigm of current radio-based transmissions, they will probably connect to some centralized "hub" (a 
reflector), that will allow broadcasting voice streams to all directly or indirectly linked users. In the next 
chapter, we also present Estrella, a D-STAR software implementation that allows communicating 
through existing reflectors without the need of any AMBE hardware. 


The open source codec, may also allow home-brewing transceivers using a Rasbperry Pi, and an at- 
tached radio, either in the form of a directly connected HAT (Hardware Attached on Top) [26], or an 
MMDVM modem [27] (even one constructed with through-hole components [28]) interfaced to a "tradi- 


tional", analog radio. The necessary software could run on the Raspberry Pi itself, assuming a method to 
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attach a microphone and speaker, or — more likely — on a mobile device running an Estrella variation that 
instead of transmitting streams directly over the Internet, sends them to the Raspberry Pi over Bluetooth 
(and vice versa), using an established D-STAR over-the-network protocol like DExtra. Such a setup, 
which has the user interface separate from the radio instance, may allow a variety of interesting, interop- 
erable implementations, that may in turn cover a multitude of different usability and physical deploy- 


ment requirements. 
3. Implementation 


The D-STAR vocoder extension has been implemented in three separate, but interoperable, projects: 

¢ pydv: A Python library and an associated set of executable command-line utilities to interface with D- 
STAR reflectors and transcode saved voice streams, either locally, or using the transcoding server 
employed by xlxd (ambed). 

¢ chazapis/xlxd: A "fork" of the leading software used to implement D-STAR reflectors, enhanced with 
the ability to recognize and transcode Codec 2-based streams to AMBE and vice versa when the ap- 
propriate hardware is present. Used as a communications hub for D-STAR software clients imple- 
menting the extension and a bridge between such clients and devices (repeaters or hotspots) serving 
AMBE-only transceivers. 

¢ Estrella: A software-only D-STAR application that implement Codec 2-based communications via a 
compatible reflector (like the aforementioned xlxd fork). Estrella is available for macOS and iOS, 


while an Android version is in the works. 


All the projects above are open source (licensed under GPL) and freely available at GitHub [29, 30, 31, 
32]. Further details for each are presented in the following paragraphs. 


3.1. pydv 


The pydv project was originally developed as a loose collection of code to assist in the early stages of 
development of the extension. Now — at version 2.0 — it provides Python interfaces to manage DExtra 
and DPlus connections, convert from network data to D-STAR streams and vice versa, save and load 
such streams to/from .dvtool files [33], as well as encode and decode voice data using Codec 2 or 
AMBE (decode only via mbelib [34]), and transcode via a compatible ambed server (included in chaza- 
pis/xlxd). 


The following command-line executables are included: 

¢ dv-recorder, which connects to a reflector and records traffic in .dvtool files 

e dv-player, which plays back a .dvtool file to a reflector 

e dv-encoder, which converts a .wav file to a .dvtool file using the Codec 2 vocoder 

e dv-decoder, which converts a .dvtool file using any vocoder to .wav 

e dv-transcoder, which connects to an ambed server and converts a .dvtool file using the AMBE 


vocoder to a .dvtool file using the Codec 2 vocoder and vice versa 
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These utilities can prove useful to anyone experimenting with D-STAR in general. As a library, pydv 
may support higher-level applications that require D-STAR reflector connectivity using any of the sup- 
ported protocols. pydv is written in Python 2.7. Future work includes porting it to Python 3, as well as 


implementing more digital voice network protocols. 
3.2. chazapis/xlxd 


xlxd is the most modern D-STAR reflector software. In essence, the function of a reflector is simple: it 
provides network protocol handlers for clients to connect and submit digital voice streams to specific 
"modules" (connection contexts, virtual "rooms"). The reflector relays each stream, in real time, to any 
client connected via any protocol to the same module. Some reflectors can even connect as clients to 
other reflectors, organizing the network traffic in cross-country or cross-continent meshes, and enabling 
ad hoc linking of talk groups together based on group-specific policy and habits [35]. 


There are various already established D-STAR network protocol variants. xlxd implements them all, 
thus allowing interoperability between them. As such, it can be deployed as either a DPlus, DExtra, or 
DCS-compatible reflector, using REF, XRF, or DCS callsign prefixes respectively (or all of the above 
simultaneously). By advertising a reflector installation to the appropriate callsign-to-IP resolution reg- 
istries, clients can use standard D-STAR commands to establish repeater/hotspot links to the reflector. 
Moreover, xlxd introduces the notion of cross-reflector "trunks" (using the XLX protocol), which con- 
vey the streams of many modules simultaneously, in practice "extending" part of one reflector from one 


installation to another. A group of linked reflectors is commonly called a "constellation". 


Recently, xlxd has also been interfaced to similar DMR network structures, like the BrandMeister net- 
work [36]. DMR uses a variant of AMBE to encode/decode speech in transceivers, so the streams run- 
ning through xIxd in that case are not directly compatible with D-STAR. To cross codec barriers, a sec- 
ondary software service called ambed, provides transcoding between the two formats. ambed requires 
the presence of one or more hardware chips to decode data from one AMBE variant into voice and en- 
code it into the other. AMBE chips may have one or more channels; at least two are required to 


transcode a stream in real time. 


Given the success and momentum of xlxd, as well of the eagerness of its developers to support any new 
and exciting technologies in the digital voice arena, it seemed as the perfect candidate to base the im- 
plementation of the D-STAR vocoder extension interoperability with other modes. As discussed, be- 
cause of the extension's backwards compatibility, xlxd could be deployed as-is to support Codec 2-based 
clients using any existing D-STAR network protocol, but such an arrangement would magnify incompat- 
ibility issues. Instead it was decided to work first — before even starting implementing clients — in the 


direction of providing a unified substrate for codec-independent communications. 


To this end, the xlxd/ambed project was forked and patched as necessary to transcode and bridge voice 


streams of any existing format to the new extension. The solution implements an additional DExtra lis- 
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tener on a different port (30201 instead of 30001). The new port is to be used by reflectors with the 
"ORF" callsign prefix (Open ReFlector). Any client connected to an ORF reflector will receive streams 
encoded with Codec 2. All other protocol handlers will still send out data encoded with AMBE. Note 
that the protocol/port only affects data transmitted by the reflector. The stream codec is recognized by all 
protocol handlers, so a client can still transmit data using any codec on any port. The rationale behind 
this is that DExtra links may be used by repeaters or other reflectors, so it is not really possible to know 
what their clients support. So, nothing will change when linking a repeater to an XRF reflector, but will 
do when linking to an ORF one. The new port endpoint has been named "DExtra Open" to distinguish it 
from the protocol running on the default DExtra port. 


A detailed outline of the code changes done is attached to the pull request that has been submitted up- 
stream, so the work will eventually be included into future versions of xlxd. In summary, most of the 
effort was concentrated into ambed, so each "vocodec" channel will function with three interfaces (1 in/ 
2 out, instead of | in/1 out). Each such channel now has a (virtual) Codec 2 interface attached, along 
with the two physical ones for AMBE. When a new incoming stream presents itself, the appropriate 
transcoding channel is selected depending on the input codec. Channels are grouped together in triplets. 
Each group contains all possible permutations of respective interfaces — three channels, while only one 
channel from each group can be used at a given time. Groups represent hardware resources that cannot 
be shared between streams; channels represent input/output configurations. The rest of the work in- 
volved interfacing xlxd to the new "1 codec in, 2 codecs out" ambed interface, the new DExtra Open 


protocol listener on port 30201, etc. xlxd and ambed are written in C++. 


The latest version of chazapis/xlxd is currently running at XLX393/XRF393 [37], which is deployed on 
a Raspberry Pi and supports transcoding a single stream at a time by employing two DVMEGA DV- 
stick30 USB interfaces (Figure 2). Operation is not restricted in any way, and it can be freely used for 
testing and experimenting with new digital voice technologies. XLX393/XRF393 is also reachable via 
DMR, through TG20209 of the BrandMeister network. 


Future work includes deploying an ORF registry to track corresponding reflector deployments. The ORF 
registry will be useful for Codec 2-based software clients, in order for them to display compatible and 
available servers for connecting to. Assuming Codec 2-based D-STAR hardware devices at some point, 
the ORF registry may also tie in to repeater/hotspot software (like the ircDDB Gateway), to enable rout- 


ing respective linking requests to the appropriate DExtra Open network endpoints. 
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Figure 2: XLX393/XRF393 current hardware setup 
3.3. Estrella 


Estrella is a radio-like software-only client for DExtra Open reflectors. Two platform variations have 
been implemented: a desktop-compatible macOS version and a mobile-friendly 10S one. Both use a 
similar user interface and aim for a very simple user experience: the user enters the connectivity details 
(callsign and ORF network endpoint), and is then presented with a minimalistic screen showing the con- 
nection status and providing a PTT button to initiate transmissions (Figures 3, 4). Although direct client- 
to-client connections could be possible, it has been decided to only support reflector-based setups, in or- 
der to match as close as possible the practice of using a "traditional" RF radio transceiver, encourage the 
deployment of new reflector software that complies with the proposed vocoder extension, and foster an 
environment of interoperable cross-codec digital voice applications and devices. As mentioned, with 
chazapis/xlxd installed and the appropriate hardware, the reflector will handle transcoding and bridging 
streams of different types and protocols. 


Estrella implements the D-STAR vocoder extension and uses a linked Codec 2 library to encode and de- 
code D-STAR communications without the need of any external hardware. macOS and iOS versions are 
both are written in Objective-C, and share a significant amount of code that is abstracted into 2 libraries 
(called Frameworks in Objective-C nomenclature) [38, 39]: 

* CocoaDV, a Cocoa Framework to manage DExtra connections to D-STAR ORF reflectors 


* CocoaCodec2, a Cocoa Framework for the Codec 2 low bit-rate speech codec 


CocoaCodec?2 bundles the source code of the Codec 2 SVN repository in an Xcode-friendly format. (de- 
tails on how this was accomplished are given at its GitHub page). CocoaCodec2 is used by CocoaDV, 
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which in turn provides the necessary network and digital voice stream abstractions to Estrella. The result 


is that the core Estrella implementation only needs to concentrate on graphical user interface elements, 


handling connectivity events, stream buffering, and managing the available audio hardware. Actually, as 


the macOS and iOS core libraries have similar APIs, the respective Estrella codebases are also very sim- 


ilar. 


Estrella 


SVSOAN to CQCQCQ 


393B 
Connected 


PTT 


Figure 3: Estrella’s main window (macOS version) 


Carrier > 12:15 AM (ie 


Estrella Settings 


SV9OAN to CQCQCQ 
Connected 


Figure 4: Estrella’s main window (iOS version) 


Current plans include completing the Android variation of Estrella and releasing all binary forms on cor- 


responding online distribution services (a binary macOS version is already available for download at 


GitHub). Future versions may present a simpler user interface for configuration, by integrating server 


selection with the ORF registry, and incorporate text messaging and D-PRS functionality (exchanging 


positional data and presenting it on a map, as done by APRS [40]). 
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4. Conclusion 


In this paper, we have described the design and implementation of an extension to the D-STAR protocol 
that uses Codec 2 for voice communications, instead of — or alongside - AMBE. We hope this work to 
become a significant milestone in D-STAR evolution, as it enables the development of completely open 
end-user radios and services, seamlessly interoperating with any current deployments. Moreover, the 
method used here can support other, similar D-STAR extensions, in order to introduce new voice codecs, 


or other, more radical changes to the stream structure. 


In practice, in nearly 20 years of existence, D-STAR has already evolved in many ways. However, the 
available protocol specification does not include many details that are now considered de facto. Back 
then, it was decided to leave out some implementation specifics: the structure of text messages or loca- 
tion information included in voice streams, the routing techniques and associated callsign discovery 
methods, the format of streams when relayed over the network, etc. Many of these functions have been 
implemented in proprietary extensions, that — although mostly reverse-engineered — are for obvious rea- 
sons poorly documented. Discovering how D-STAR radios, repeaters, gateways, and reflectors work is a 
formidable task, as anyone interested can only find information in scarce Internet resources — that may 
vanish at any point — or deep into the codebase of related software projects. This unfortunate fact, nei- 
ther matches the open nature of amateur radio, nor aligns to the (presumably) original intention of the D- 
STAR design group: to publish an open document that will provide the basis of cooperation and interop- 


erability between radio amateurs and equipment manufacturing companies. 


Adoption of digital radio technologies is growing larger every year, so D-STAR is now more relevant 
than ever. Both as a standard for digital radio transmissions, and as the foundation of an Internet-based, 
worldwide communication network for amateur radio. Sooner rather than later, JARL — or any other big 
and respectable amateur radio association — should convene a new standards body to release a revised, 
modern D-STAR standard, documenting established usage of the protocol and providing new directions 
for the future. If that ever happens, hopefully an open voice codec will indeed be an option — either the 


one presented here, or any other patent-free solution; in the true spirit of amateur radio. 
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Notes — D-STAR is a registered trademark of ICOM, Inc. AMBE is a registered trademark of Digital 


Voice Systems, Inc. 
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